home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19951130-19960209 / 000261_news@columbia.edu _Tue Jan 9 16:31:48 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id QAA04318 for <kermit.misc@watsun>; Tue, 9 Jan 1996 16:31:46 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id QAA06592 for kermit.misc@watsun; Tue, 9 Jan 1996 16:31:43 -0500 (EST)
  4. Path: news.columbia.edu!panix!imci3!imci2!newsfeed.internetmci.com!howland.reston.ans.net!tank.news.pipex.net!pipex!demon!mail2news.demon.co.uk!pdlmail.demon.co.uk
  5. From: Peter Disdale <Pete@pdlmail.demon.co.uk>
  6. Newsgroups: comp.protocols.kermit.misc,comp.protocols.misc
  7. Subject: Re: No handshake xfers
  8. Date: Tue, 09 Jan 96 18:29:48 GMT
  9. Organization: Papa Delta Limited
  10. Lines: 51
  11. Message-ID: <821212188snz@pdlmail.demon.co.uk>
  12. References: <4cqnvm$iii@rigel.pixi.com> <1996Jan8.125039.70773@cc.usu.edu> <4ct372$l8i@rigel.pixi.com>
  13. Reply-To: pete@pdlmail.demon.co.uk
  14. X-NNTP-Posting-Host: pdlmail.demon.co.uk
  15. X-Newsreader: Demon Internet Simple News v1.30
  16. X-Mail2News-Path: pdlmail.demon.co.uk
  17. Xref: news.columbia.edu comp.protocols.kermit.misc:4457 comp.protocols.misc:5234
  18.  
  19. In article <4ct372$l8i@rigel.pixi.com>
  20.        chip@pixi.com "William K. Marshall" writes:
  21.  
  22. > In article <1996Jan8.125039.70773@cc.usu.edu>,
  23. >    jrd@cc.usu.edu (Joe Doupnik) wrote:
  24. > > In article <4cqnvm$iii@rigel.pixi.com>, chip@pixi.com
  25. > > (William K. Marshall) writes:
  26. > >
  27. > > > Here's one for you all...
  28. > > > [original article, all good stuff, snipped]
  29. > >
  30. > >      Dream on. No ACKs mean no protocol level flow control (and really
  31. > > no flow control at all for the truely paranoid situations), no feedback
  32. > > to the transmitter that information has become lost or damaged, no breaking
  33. > > deadlocks from lost information. A straight ASCII send and hope that it gets
  34. > > there also provides no error checking, no redundancy checking, no hole
  35. > > checking. In short, it's *The Worst Way* of transferring information.
  36. > > [..]
  37. >
  38. > The thing is that I am only using a 4 foot lenght of fiber between two 486's.
  39. > The possibility for packet loss is remote.  It is not a big deal if once in a
  40. > while the users have to re-send the data.
  41. >
  42. > [..]
  43. Sounds to me as though what you are currently doing is the best you
  44. can hope for, but consider the following:
  45. 1. you mentioned in the original post 'modems'. Can these be eliminated
  46.    and a direct connection be used instead?
  47. 2. why are you uuencoding the file? Are you limited to 7 bit characters
  48.    by the 'modems'?  If not, why not use 8 bit chars and send the ZIP
  49.    directly - this would reduce the size (and hence time) by a quarter.
  50. 3. you said that a 10 Mb file takes around 4 hours to transfer.  I might
  51.    have done my sums wrong, but that means arounds 7000 bps.  Is there
  52.    any way you can run the com ports faster than this, say at 57600 bps?
  53.    (Given of course that the 486s have 16550 UARTs.)
  54.  
  55. As Joe said, you have no way of knowing that the data arrived OK.
  56. However, using a compressor (like PKZIP) maintains its own CRC data
  57. in the file, so at least you could be fairly certain that if it was
  58. unZIPped OK, then the data would be good.
  59.  
  60. So, if you could increase the transfer rate to say, 8 times the present
  61. value, and reduce the file size by a quarter, your 10 Mb file would
  62. only be around 7.5 Mb, whose transfer time would be around 25 minutes.
  63. You might, however, need to save the file out to a RAM disk (or very
  64. fast hard disk) to avoid losing data through overruns...
  65.  
  66. Good luck!
  67. --
  68. Pete